feat: 컬렉션 모듈 및 마이페이지 진입 구조 구현 - #941

activity로 두는게 아닌 SAA 형태로 조금씩 바꾸는게 좋을 것 같습니다. 굳이 레거시 구조를 유지할 이유가 없는 것 같아요

SAA를 지향하는 방향에는 공감합니다!
다만 현재 앱에는 앱 레벨의 Compose NavHost가 없고, MainActivity가 FragmentContainerView와 FragmentManager를 통해 홈/피드/서재/마이페이지 Fragment를 직접 전환하고 있습니다.
MyPageFragment 역시 이번 작업에서 추가한 것이 아니라 기존 화면입니다.
컬렉션 진입 구조를 설계하면서 아래와 같은 방법들을 고려해보았습니다.

• CollectionFragment를 추가하면 기존 Fragment 구조를 다시 확장하게 됩니다.
• 컬렉션을 MainActivity의 Compose destination으로 연결하려면 하단 탭, 기존 Fragment 호스팅, 뒤로 가기 처리를 포함한 앱 단위 내비게이션 변경이 필요합니다.
• 별도 CollectionActivity를 사용하면 기존 마이페이지와 메인 내비게이션에는 영향을 주지 않으면서, 새로 개발하는 컬렉션 내부 흐름은 Compose Navigation으로 구성할 수 있습니다.

이번 PR은 컬렉션 기능을 단계적으로 추가하는 첫 PR이기 때문에 기존 화면의 마이그레이션까지 범위를 넓히기보다, 수정 범위를 컬렉션에 집중하는 편이 안전하다고 판단해 CollectionActivity를 진입 경계로 선택했습니다. Activity가 추가되어 향후 SAA 전환 시 마이그레이션 대상이 늘어난다는 단점은 있지만, 현재 구조와 PR 범위에서는 가장 적절한 선택이라고 보았습니다.
SAA 로의 전환은 MainActivity 내비게이션 마이그레이션 작업으로 별도 분리하는 것이 적절하다고 생각합니다.
혹시 기존 메인 구조를 크게 변경하지 않으면서 이번 PR에서 점진적으로 적용할 수 있다고 생각하신 구체적인 구조가 있다면 의견 부탁드립니다!

+공식 Android 문서에서도 기존 View/Fragment 앱은 Compose와 공존시키며 화면 단위로 점진적으로 이전하도록 권장하고 있습니다. Fragment가 남아 있는 동안 ComposeView를 사용하는 것도 전환 방식으로 안내하고 있으며, 모든 navigation destination을 Composable로 전환할 수 있을 때 Navigation Compose로 마이그레이션하도록 설명하고 있습니다.
Compose 마이그레이션 전략, ComposeView와 Fragment 연동

fragment도 현재 compose 환경에서는 잘 사용되지 않아 레거시인것 같습니다.

Compose-first 구조의 최종 방향에서 Fragment를 제거하는 것이 좋다는 점에는 공감합니다!
다만 MyPageFragment는 이번 작업에서 새로 추가한 것이 아니라 기존 MainActivity의 마이페이지 탭을 구성하던 화면입니다. 이번 PR에서는 기존 마이페이지 전체를 변경하지 않고 컬렉션 진입부만 Compose로 구현하기 위해 ComposeView를 추가했습니다.

MyPageFragment를 제거하려면 기존 마이페이지 XML과 ViewModel 연결, 스크롤 및 툴바 동작 등 컬렉션과 관계없는 영역까지 함께 마이그레이션해야 합니다. 해당 작업은 이번 컬렉션 PR의 범위를 크게 벗어나기 때문에, 따라서 이번에는 기존 Fragment를 유지하고 ComposeView로 점진적 적용하게끔 선택했습니다. 마이페이지 전체의 Compose 전환은 별도 작업으로 분리하는 것이 안전하다고 판단했습니다.

마이페이지 전체를 compose로 분리하는 것이 아닌 MyPageFragment, HomeFragment, FeedFragment는 지금 그대로 MainActivity의 탭으로 두고, 컬렉션만 앱 레벨 Compose NavHost의 destination으로 붙이면 마이페이지에 대한 이전은 나중에 하고 collection만 간단하게 변경할 수 있을거라 생각됩니다!

여기 ai가 알려준 상세 코드 첨부합니다.
구체적인 방법: MainActivity에 얇은 NavHost 레이어 추가

activity_main.xml에 fcv_main 위를 덮는 ComposeView 하나만 추가합니다.

<androidx.compose.ui.platform.ComposeView
android:id="@+id/cv_main_overlay"
android:layout_width="0dp"
android:layout_height="0dp"
android:visibility="gone"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />

MainActivity에 앱 레벨 NavHost를 두되, startDestination은 아무것도 그리지 않는 main 으로 둡니다. 즉 기본 상태에서는 기존 Fragment 화면이 그대로 보이고, Compose destination으로
이동한 순간에만 오버레이가 올라옵니다.

// app/src/main/java/com/into/websoso/ui/main/AppNavHost.kt
@composable
fun AppNavHost(
navController: NavHostController,
modifier: Modifier = Modifier,
) {
NavHost(navController, startDestination = MainRoute, modifier = modifier) {
composable { } // Fragment 탭 영역 — 아무것도 그리지 않음
collectionNavGraph(navController) // feature:collection이 제공하는 그래프
}
}

// MainActivity                                                                                                                                                                    

private lateinit var navController: NavHostController

private fun setupComposeNavHost() {
binding.cvMainOverlay.apply {
setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
setContent {
navController = rememberNavController()
WebsosoTheme { AppNavHost(navController) }

          val entry by navController.currentBackStackEntryAsState()                                                                                                              
          val isRoot = entry?.destination?.hasRoute<MainRoute>() ?: true                                                                                                         
          LaunchedEffect(isRoot) {                                                                                                                                               
              binding.cvMainOverlay.isVisible = !isRoot                                                                                                                          
              binding.fcvMain.isVisible = isRoot                                                                                                                                 
              binding.bnvMain.isVisible = isRoot                                                                                                                                 
              binding.viewMainDivider.isVisible = isRoot                                                                                                                         
              backPressedCallback.isEnabled = isRoot   // ★ 중요                                                                                                                 
          }                                                                                                                                                                      
      }                                                                                                                                                                          
  }                                                                                                                                                                              

}

지금 아키텍쳐가 feature based layered architecture 구조인데 feature에 대한 데이터 모듈과 feed가 같은 레벨에 있는게 조금 이상한 것 같습니다

확인해 보니 코멘트가 달린 implementation(projects.data.feed) 의존성은 기존에 존재하던 코드이고, 이번 PR에서 app/build.gradle.kts에 추가한 의존성은 implementation(projects.feature.collection) 한 줄입니다.
feature.collection은 기존 feature.signin, feature.library, feature.feed와 동일한 feature 레벨에 추가했습니다. 또한 이번 PR에는 컬렉션 API나 데이터·도메인 로직이 포함되지 않아 collection용 data/domain 모듈은 아직 추가하지 않았습니다.
혹시 기존 app → data.feed/domain.feed 직접 의존 구조를 말씀하신 것인지, 아니면 이번에 추가한 feature.collection의 모듈 위치가 적절하지 않다는 의견인지 확인 부탁드립니다.
후자라면 생각하신 구체적인 모듈 배치나 의존 방향을 알려주시면 다시 고려해보겠습니다!

말씀하신 부분을 app이 data.feed, domain.feed, feature.feed를 모두 직접 의존하고 있어 feature 기반 의존 방향과 맞지 않는다는 의미로 이해했습니다.
확인해 보니 현재 app의 기존 피드 상세 및 작성 화면에서 data.feed의 Repository와 Entity를 직접 사용하고 있어 해당 의존성이 남아 있습니다. 이 부분은 이번 PR에서 추가된 의존성이 아니라 기존 피드 모듈화 과정에서 남아 있는 구조이며, 제거하려면 관련 피드 화면과 데이터 참조를 함께 feature.feed 쪽으로 이전해야 할 것 같습니다.
이번 PR에서 app/build.gradle.kts에 추가한 것은 projects.feature.collection 한 줄이며, 컬렉션에는 아직 데이터 계층이 포함되지 않습니다. 기존 app → data.feed/domain.feed 의존 정리는 피드 모듈화 작업으로 별도 분리하는 것이 적절하다고 생각하는데, 제가 리뷰 의도를 맞게 이해했을까요?

네 맞습니다 지금 collection의 모듈에는 data, domain, presentation 이렇게 있어야 될거같은데, data와 domain 이 collectio모듈과 같은 레벨에 있어 개념상 맞지 않는다고 판단했습니다. 그래서 collection/data, domain, presentation 이렇게 하위 모듈로 가져가고 각 feature끼리는 domain 만 서로 의존하는 것이 더 좋은 설계인 것 같습니다! 다만 변경 범위가 커서 collection 만 우선적으로 옮겨가는 것이 좋아보입니다.